Manufacturers of various types of network-connectable devices may require or desire the ability to test the functionality of a network interface, such as an Ethernet network interface card (NIC). The datalink layer and physical (PHY) layer circuitry of a network interface are sometimes collectively called the “hardware layer”. One of the most common ways to test the hardware layer of a network interface is by a loopback test. In a loopback test, a cable is connected from the output to the input of the network interface. Data is then sent out of the network interface, and the loopback cable sends this data back into the network interface.
This type of test can be performed by setting up a TCP server on the device under test (DUT) that listens on a particular port. A client program attempts a TCP connection to the DUT's IP address, and sends the data. When the server program receives this data, it performs a checksum comparison to validate the integrity of the data, and therefore, the functionality of the DUT's hardware layer. If the data received matches the data sent, the DUT (the network interface) is considered to be functional.
It is desirable to be able to initiate a hardware layer loopback test from user-space software, e.g., from test software operating logically above the operating system. However, certain operating systems, such as Linux version 2.4, do not allow a Transport Control Protocol/Internet Protocol (TCP/IP) packet to be passed down to the hardware layer if the packet is destined for one of the host machine's own IP addresses. Instead, when the operating system receives such a packet from the user-space software, the operating system performs a software loopback within its IP layer. Thus, Linux version 2.4 and other operating systems which operate in this way are not designed to allow a hardware layer loopback test of a network interface.
One way to avoid this problem, assuming such an operating system is to be used, would be to modify the operating system kernel code to bypass or disable the software loopback functionality. However, changing the operating system kernel code can be time-consuming and costly. Furthermore, this approach tends to complicate the manufacturing process, because the manufacturer would then have multiple kernels to manage, i.e., one for regular use in its products, and one for running its manufacturing testing tools.
Another possible approach would be to connect the DUT to a separate test host machine and send data back and forth between these machines to verify the DUT's hardware layer functionality. However, this method is also expensive, since it requires a test host for each DUT, and it does not scale well in a typical manufacturing setup due to cost and manufacturing bench space limitations. Furthermore, this approach is not true loopback testing of the DUT, since the data must travel to a separate host on the network before being sent back to the DUT.